-
Notifications
You must be signed in to change notification settings - Fork 798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add block provider to core-fellowship #6978
base: master
Are you sure you want to change the base?
Add block provider to core-fellowship #6978
Conversation
This reverts commit cdd6c92.
…re-block-provider
…re-block-provider
Sorry, only members of the organization paritytech members can run commands. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have to review the migration
cumulus/parachains/runtimes/collectives/collectives-westend/Cargo.toml
Outdated
Show resolved
Hide resolved
cumulus/parachains/runtimes/collectives/collectives-westend/src/lib.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, once the comments are resolved
EDIT: Okay should be good to re-review now 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
Following #3617, core fellowship and related code is to be made async backing friendly. This PR adds the block number provider config parameter to pallet-core-fellowship.
In addition it
TODO:
Once Westend is updated I will write the migration for polkadot collectives.
Notes:
@xlc This will be my first migration and overall first PR with a bit more frame complexity, so please review carefully!
I've tested the migration for Westend using try-runtime. Unsure what the standard process is outside of that if any.
Also, the migration assumes consistent block times for westend and westend collectives, which is not the case, but I imagine this is not so much a concern and will largely be ameliorated when writing for polkadot collectives. Lastly, not confident in the runtime spec_version bump, that was a bit opaque to me, if you want to take a look.
@gupnik Tracking list